4 


NASA Technical Memorandum 100835 


Laboratory Information Management System 
(LIMS)— A Case Study 

(NASA-TM— 100835) LABORATORY INFORMATION N88-21697 

MANAGEMENT SYSTEM (LIMS): A CASE STUOY 
(NASA) 18 p CSCL o9B 

Unclas 

G3/62 0136315 


Karen S. Crandall and Judith V. Auping 
Lewis Research Center 
Cleveland, Ohio 

and 

Robert G. Megargle 
Cleveland State University 
Cleveland, Ohio 


Prepared for the 

First International Laboratory Information Management Systems Meeting 
Pittsburgh, Pennsylvania, June 23-25, 1987 


f " ‘ 

- • v 

f\l/\SA 


LABORATORY INFORMATION MANAGEMENT SYSTEM (LIMS) - A CASE STUDY 


Karen S. Crandall and Judith V. Auping 
National Aeronautics and Space Administration 
Lewis Research Center 
Cleveland, Ohio 44135 

and 

Robert G. Megargle* 

Cleveland State University 
Cleveland, Ohio 441 15 


SUMMARY 

In the late 1970' s, a refurbishment of the analytical laboratories serving 
the Materials Division at the NASA Lewis Research Center was undertaken. As 
part of the modernization efforts, a Laboratory Information Management System 
(LIMS) was to be included. Preliminary studies indicated a custom-designed 
system as the best choice in order to satisfy all of the requirements. A 
scaled-down version of the original design has been in operation since 1984. 

The LIMS, a combination of computer hardware and software, provides the chemi- 
cal characterization laboratory with an information data base, a report genera- 
tor, a user interface, and networking capabilities. This paper is an account 
of the processes involved in designing and implementing that LIMS. 


INTRODUCTION 

A customized Laboratory Information Management System (LIMS) has been in 
place since October, 1984 in the Analytical Science Branch of the NASA Lewis 
Research Center. Two laboratories located in adjacent buildings make up the 
branch, one laboratory specializing in chemical analysis, the other in micro- 
structural analysis. These laboratories provide analyses to a materials 
research division active in the areas of ceramics, metallic alloys, metal 
matrix composites, polymers, and coatings. The annual workload averages 
about 10 000 samples, most of a nonroutine nature. In the late 1970's, a major 
refurbishment of the laboratory facilities was undertaken. As part of that 
refurbishment, the lab management began investigating the possibility of com- 
puterizing the sample submission and reporting process. With the relatively 
small sample load, sample tracking had not been a problem under the previous 
manual system. In fact, many of the benefits that large analytical labs obtain 
by computerization simply did not apply to a small lab serving a research com- 
munity. The major advantages that were desired in a new system were a conven- 
ient, one-stop sample submittal procedure for researchers, easier access to 
past analysis results, the capability of retrieving consolidated data on 
research projects lasting several years, and the availability of a wide vari- 
ety of management statistics that would indicate, for example, which research 
projects used the bulk of the analytical services. 
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WHY A LIMS? 


In the mid-1970's, local area networks and laboratory information manage- 
ment systems were rapidly becoming "state-of-the-art" for data transmission 
and data handling in many large analytical laboratories. This technology 
offered the Analytical Science Branch a way to "connect" its two laboratories 
and provide consolidation of management reports. 

A feasibility study done by Lawrence Livermore Laboratories of Livermore, 
California weighing benefits versus costs of a LIMS proved encouraging. A sec- 
ond contractor, Purvis Systems Inc., of Syosset, New York was hired to deter- 
mine the functional requirements and the design specifications of a LIMS. A 
characterization of the flow of information through the laboratory was done as 
part of the initial studies. The results of this characterization were used 
to determine the critical areas in the LIMS implementation design. The study 
indicated that the manual system used by the staff in both analytical labora- 
tories for sample submission and analysis reporting was quite efficient. The 
computerized version of these procedures was to mimic that format as much as 
possible. 

Potential improvements that a LIMS could provide included a computerized 
instrument maintenance schedule and repair log; an instrument usage report; a 
systematic quality control program; an inventory of supplies used in the labo- 
ratories; a computerized scheduling log for microscopes used directly by the 
researchers; easier consolidation and accumulation of management report data; 
and analytical results obtained in machine-readable format which could be 
utilized in data reduction and analysis programs resident on other computers. 

As part of the design phase, each of the laboratories was divided into a 
number of "workstations". A workstation was defined to consist of one or more 
instruments or analytical techniques assigned to an analyst. The LIMS would 
connect each of the workstations to the LIMS computer via the Lewis Information 
Network (LINK, see appendix A), a local area cable network installed throughout 
NASA Lewis. As a long range goal, each of the instrument's computers could be 
added to the Lewis network for transferring of analytical results directly to 
the LIMS computer. 


HARDWARE AND SOFTWARE 

The hardware recommended by Purvis and subsequently procured included two 
Digital Equipment Corporation's PDP 11/24 computers - one to serve as the LIMS 
processor and the other to be used during the development phase and also to be 
a backup for the LIMS computer and provide additional computer resources to the 
materials research division. The PDP 11 /24s were equipped with three 10 mega- 
byte disk drives - a system disk, a data disk, and a journaling or backup disk. * 

In the proposed LIMS, the system disk would contain the operating system and 
database programs; the data disk would contain the database records including 
the dictionaries; and the journaling disk would keep a log of system changes 
and error messages and be used for making backups of both the system and data 
disks. Each computer was configured with 1.25 megabytes of main memory. 

The terminals selected for use with the LIMS were DEC VTlOOs, VT 125s, and 
a Decwriter III to be used as the system console. The printers selected were a 
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DEC LA TOO letter quality printer for reports and Integral Data Systems Prism 
dot matrix printers for interim reports, customer receipts, and sample labels. 

A Racal Vadic auto-answer modem was purchased for off-site access to the LIMS. 
This modem was and continues to be used for software development. The work- 
station terminals were to be connected to a bus Interface unit (BIU, see 
appendix A) which would provide the protocol for transmitting LIMS communica- 
tions over the NASA Lewis cable network. 

Two operating systems were procured, Digital Standard MUMPS (DSM -11) and 
RSX-11M. RSX-11M was used for developing the network code needed by the BIUs 
and DSM-11 was chosen for the LIMS software development. MUMPS (Massachusetts 
General Hospital Utility Multi-Programming System) is a high-level, interpreted 
programming language which was developed at the Massachusetts General Hospital 
Laboratory of Computer Science. It provides dynamic memory allocation and a 
tree data structure. This type of data structure allows for easy database mod- 
ification, growth and fast data retrieval. 


LIMS SOFTWARE DESIGN SPECIFICATIONS 

Certain guidelines were established by the project team in creating the 
functional design of the LIMS. Of primary importance was that the system be 
easy to use and menu driven. The number of key strokes necessary to access 
the various functions were to be kept at a minimum. In order to protect the 
integrity of the system and yet include a wide range of functions, it was sug- 
gested that a password system be used along with different classes of users. 
Four classes of users were chosen: manager, analyst, customer and guest. As a 
user logged on to the system, the class would be checked, and he or she would 
only be given access to the appropriate functions. 

The main design specifications fell into the following categories, each of 
which will be discussed separately: 

Dictionaries and Menus 
Sample Management Functions 
Laboratory Database Functions 
Management Reporting Functions 
Interface to Local Area Network 
Ancillary Functions 


Dictionaries and Menus 

A series of data dictionaries was proposed to store information that 
remained relatively fixed over time, but required periodic updating. Separate 
dictionaries were created to store data about users, workstations, instruments, 
test codes, and accounting charges. Besides the obvious benefit of allowing 
the LIMS to be recustomized to any changes in lab capabilities or organization, 
the dictionaries would help minimize keystrokes in entering analysis requests. 
In particular, the user information dictionary, which was keyed to the initials 
of the users, would allow both lab personnel and researchers to identify them- 
selves to the LIMS simply by entering their initials, rather than having to 
type in their name and identifying information each time they used the system. 
These dictionaries were to be maintained by the LIMS manger. Figure 1 shows an 
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example of the data entry screens used to enter or edit data in the diction- 
aries, in this case, the user information dictionary. 

For each class of user, access to the LIMS routines was to be controlled 
by a different set of nested menus. When a user logged on to the LIMS using 
his or her initials and password, the log-on routine would check the class of 
the user and present the appropriate top-level menu for that class. The menus 
were structured so that managers could access all LIMS functions or routines; 
analysts could use only those routines involving analysis data and results, 
time and record keeping, and word processing; and the customer or guest could 
access only his or her analysis requests and sample status. (The distinction 
between customer and guest was that a customer had to have a password and be 
"known" to the LIMS. A guest was to be permitted to log on using his or her 
initials as password strictly for the purpose of submitting samples. Guests 
would either have to wait for hard copies of analysis results to be mailed to 
them or change their status to customers in order to query the LIMS directly 
about their analyses.) Figures 2 through 4 illustrate the top-level menu for 
the different classes of users. 


Sample Management Functions 

The sample management functions included requests for analysis, the capa- 
bility of checking on the status of samples submitted for analysis, entering 
analysis results, generating analysis reports, displaying queue lists for each 
workstation, and storing exception log entries - changes made to the database 
by the analysts or manager (i.e., addition or deletion of test requests, edit- 
ing of sample data, or analysis results, and so forth). 

Samples were to be identified in the database by a computer-generated 
seven-digit number. The first digit would represent the last digit of the fis- 
cal year, the next four digits were to contain the batch number ranging from 
0001 to 9999, and the last two digits to indicate the sample number within the 
batch from 01 to 99. As an example of this scheme, 7012304 is the fourth sam- 
ple of the 123rd batch submitted in fiscal 1987. (Note that this numbering 
scheme, designed in 1980, will provide unique sample numbers for only 10 years. 
We are currently anticipating some problems as the year digit "rolls over" in 
1990. Designers of future systems would do well to anticipate the century 
roll over in the year 2000.) 

Submitting a sample for analysis would require the researcher to enter a 
task number for accounting purposes as well as various identifying information 
such as phone number, mail stop, and so forth as shown in figure 5. Normally, 
much of this information would be automatical ly retrieved from the user infor- 
mation dictionary and the form completed with the researcher being allowed to 
edit the information if needed. A project link number could be added for iden- 
tifying batches common to a specific, long-range project. A short textual 
description of the batch of samples could also be added. 

Once this form was completed the batch number was assigned. The next 
form requested that a unique sample identifier be entered, an optional sample 
description and the analytical tests to be performed. When each sample had 
been entered, the submitter would review a summary of the samples submitted and 
the tests requested and could choose to edit the information, print receipts 


4 



and sample labels. Researchers could also check on the status of all samples 
submitted within a three year period. (Each data disk would contain only 
3 years of data in order to permit faster data retrieval.) 

The analysts were to be responsible for assigning samples to the appropri- 
ate workstation, entering analysis results and generating analysis reports. On 
demand, LIMS would provide the analysts with a queue list of all samples await- 
ing analysis for a particular workstation. These queue lists could either be 
displayed on a CRT or be printed. The queue list would display sample numbers 
and descriptions along with information such as date submitted, name of submit- 
ter, tests requested, and the current status. Once the batch was analyzed and 
the results entered in the system and verified by the analyst, it would be 
removed from the queue lists. 

The analyst's menu was designed to be a multi-level menu. Submenus would 
offer editing of test requests and analytical results, options for comments to 
the submitter, notes to other analysts, word processing, mailing labels, and 
so forth. 


Laboratory Database Functions 

The LIMS was to provide improved bookkeeping features for the laborato- 
ries. Listings of analytical instruments, workstations, and outside contract 
laboratories stored in dictionaries would allow easy updating of the laboratory 
capabilities report. An inventory of supplies was desired so that the LIMS 
manager would be alerted when items should be reordered. Scheduling of micro- 
scopes used directly by the research staff and an instrument log of maintenance 
and downtime were two other features LIMS would provide. 


Standard Management Reports 

One of the most desired features of the LIMS was its ability to easily 
generate management reports. The analysts were routinely required to compile 
lists of all samples submitted from the various research groups and compute 
the relative amounts of time spent on the analyses. Funding for the labs was 
apportioned from the research group project accounts in proportion to the 
amount of analytical services requested and used to compensate for instrument 
maintenance and replacement. A LIMS could generate these reports in a fraction 
of the time required of the analysts to do it manually. 


Interface to Local Area Network 

The LIMS design included use of the LINK broadband cable network as the 
means of connecting remote terminals and instrument computers to the LIMS com- 
puter. This feature offered researchers throughout Lewis the possibility of 
being able to access the LIMS from any terminal connected to the cable network. 
It also allowed for the possibility of creating a communications link from the 
LIMS computer to the NASA Lewis mainframe computers. The analysts would be 
able to use application packages resident on those computers for further data 
reduction or statistical analysis. 
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Anci 1 lary Functions 


Other functions that were included in the LIMS design were on-line help, 
a quality control subsystem, and word processing. The on-line help was to be 
available at each request for user input. It would range from one or two lines 
of text to more detailed explanations when necessary. Each menu was to include 
a help text to explain the menu selections. 

A systematic way of performing quality control on analytical techniques 
would be developed which would mark and identify samples to the LIMS as quality 
control samples. The results would be accumulated and stored in the database to 
provide a history for the instruments and a check of the quality of the analyt- 
ical technique. 

IMAGE, a word processing package which runs under DSM-11 was selected to 
provide text storage capabilities for the analysts. MUMPS was not designed for 
easy storage of large amounts of text within a database structure. Special 
programs must be written to handle the storage and retrieval of each 255 char- 
acter string in text format. The use of IMAGE by the analysts would give them 
the capability to compose and store such items as descriptions of analytical 
techniques, detailed explanations of unexpected analytical results, and memos. 

The LIMS was to provide access to DSM-11 system operations for managing 
and maintaining the database. Access to this part of the LIMS was to be avail- 
able only to the manager class of users. The most useful of the DSM-11 utili- 
ties include routines for quick searching and editing of the database, for 
maintaining terminals and printers, and for performing system backups. 


LIMS SOFTWARE CONTRACT 

The LIMS design was formidable and the preliminary studies determined that 
no existing commercially available LIMS could provide all the functionality 
requested, particularly the networking capabilities. A contract was drawn up 
to have the software custom written and a vendor was selected. During negotia- 
tions, some of the LIMS features were designated as optional, to be implemented 
if time and funding permitted. These included the quality control subsystem 
and the on-line help. The vendor proposed a schedule for software development, 
system testing, and analyst training. After approximately eight months, the 
system was delivered for initial testing. It was quickly apparent that there 
were serious problems with the software package. Errors in data entry often 
caused routines to crash and leave the user at the DSM-11 system prompt 
instead of displaying an error message and prompting the user to enter another 
response. The vendor requested both time and funding extensions to correct the 
software. A time extension was granted; however, during the second attempt at 
on-site testing, it was quite evident that the LIMS would be unusable without <> 

major revisions and that the vendor was not in a position to provide the revi- 
sions satisfactorily. 


LIMS REVISION 

At this point, three options were available: abandon the project, 

request additional funds for another vendor to finish the project, or finish 
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it in-house. Trying to secure additional funds to continue with another vendor 
was not a possibility since the project was beyond its completion date and was 
well over budget. 

The idea to abandon the project was gaining favor with management for sev- 
eral reasons. The in-house development of the interface to the local area net- 
work was not going smoothly. The frequency on the broadband cable that had 
been allocated for the project had been changed after most of the programming 
of the interface units had been done. This had required major hardware modi- 
t fications at significant cost in order for the units to operate at the new 

frequency. The communications between the LIMS computer and the Bills had 
intermittent problems, the most serious of which caused single terminals to 
randomly lock up. The only apparent means for reestablishing communications 
to the affected terminal was to reset a board on the LIMS computer which would 
adversely affect other users accessing the LIMS over the network. This problem 
remained unsolved despite many months of effort and cast serious doubt on the 
prospect of using the network for all terminal connections to the LIMS. 

Resistance to the LIMS was still being voiced by the analysts in the 
mi crostructural laboratory. They had not been convinced that the LIMS would 
provide them with any real benefits and they were concerned that too much time 
and effort would be required to input their analysis results in a LIMS- 
compatible format. 

An in-house project team was consulted as to the feasibility of finishing 
the project at Lewis. Reviewing the state of the project and assessing the 
various stages of its completion the team concluded that by radically modifying 
the original design, a scaled-down version of the LIMS could be implemented for 
use in the chemical characterization laboratory only. 

The modifications included: 

• eliminating the microstructural laboratory from the design 

• designing the video output specifically for VT100 terminals 

• debugging the manager class of programs and rewriting the analysts 

and customers programs 

• including on-line help 

• postponing the inventory and instrument repair logs 


LIMS IMPLEMENTATION AND TRAINING 

The in-house team spent seven months rewriting the software while work 
continued on solving the BIU communications problem. The system was tested for 
major flaws and revised accordingly. Training began in August, 1984 for the 
analysts with a two-day seminar on the LIMS, including hands-on demonstrations. 
During the next two months, the analysts provided the fine tuning of the sys- 
tem, finding subtle errors in the programs and requesting improvements in the 
display and reporting features. The manual paper system was maintained for 
1 year while the LIMS database proved its reliability and the analysts handled 
all of the data input to the LIMS. 

During that year, minor modifications and improvements were added to the 
system. The LIMS computer was moved into the laboratory where terminals were 
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positioned for easy access by both analysts and researchers. Because the BIU 
communications problems had not been satisfactorily resolved to allow for reli- 
able network communications, all user terminals were connected directly to the 
LIMS computer. In January, 1986 the researchers became LIMS users and were 
required to enter their own sample analysis requests to the LIMS. 

Training for the researchers was done on an individual, as-needed basis 
with the analysts and LIMS manager serving as tutors. The help screens were 
compiled into a manual and information sheets for accessing the system were 
readily available at the researchers' terminals. A remote terminal was still 
maintained for the analysts and it is currently using a different type of 
modem. This type provides the connection to and from the LINK for most of the 
terminals and personal computers in use at NASA Lewis. 


FUTURE LIMS PROJECTS 

The idea of direct data transfer from the analytical instruments to the 
LIMS is still being pursued. The ICP emission spectrometer computer, a PDP 
11/23, will be connected via the LINK within the next year. This will allow 
for the direct transfer of ICP analysis results to the LIMS computer and also 
provide the ICP terminal with the LIMS terminal capabilities. 

There is some discussion about implementing a small LIMS in the micro- 
structural laboratory to handle bookkeeping functions, scheduling of user 
instruments, and maintaining an inventory of supplies. The LIMS has demon- 
strated tangible benefits that could apply equally well to the mi crostructural 
laboratory. 


MAINTENANCE 

The LIMS has required very little maintenance, both in hardware and soft- 
ware. Periodic maintenance is performed annually on the hardware to ensure 
optimum performance and locate potential hardware problems. Disk backups are 
currently performed twice a week on the data and any time a change is made to 
the system software. Archiving of analytical data is done so that only three 
years of data is stored on a data disk. 

The LIMS manager is required to have experience with MUMPS programming 
and have an understanding of the database structure. He or she is responsible 
for maintaining the software and for scheduling maintenance of the hardware. 
On-site contractors provide the hardware maintenance support. Both maintenance 
capabilites have provided quick response times for LIMS-related problems and 
have allowed implementation of user suggestions to the software. 


ENHANCEMENTS 

Enhancements have been made to the system including an electronic time 
card function with which the analysts can record the amount of time they spend 
on different projects. A partial report option was added so that the resear- 
chers could receive the analytical results from those workstations finished 
with their part of the analysis. In the original design, researchers had to 
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wait for all tests requested at all workstations to be completed before receiv- 
ing an analysis report on a batch of samples. 


BENEFITS 

The LIMS has provided a number of benefits to the analytical laboratory: 
the central storage of analysis results, the ease of data retrieval, and a 
variety of management reports to name a few. A side benefit is that the ana- 
lysts have become more computer literate due to the in-house development effort 
and are less reluctant to try new computerized equipment. 

Personal computers have also found their place within the research organi- 
zation and are used in various capacities, from word processing, spreadsheets, 
graphics and databases to data acquisition and instrument control. The growth 
of this industry and increase in storage capacities of the new PC, indicate 
that a personal computer may be a good choice for the main computer of a small 
LIMS. 


CONCLUSIONS 

When this LIMS was being designed, in the late 1970s, there was very 
little in the literature to assist with choosing a LIMS or to warn prospective 
LIMS designers of the pitfalls in a custom-designed system. Technology was 
changing rapidly in the computer industry and standards were still being 
decided upon in the area of local area networks. The cost of commercially 
available LIMS software was in the $60 000 or more range with custom software 
ranging upwards of $150 000. 

Today, much has been written on the subject of LIMS dealing with methods 
for determining if your laboratory can benefit from a LIMS, what LIMS features 
are necessary to meet your needs, choosing the right hardware and software, and 
what the staffing requirements are for maintaining a LIMS. Prices for commer- 
cially available minicomputer-based LIMS systems depend on the number of feat- 
ures included and the type of hardware desired. In 1985, prices for both 
hardware and software costs ranged from $15 000 to $600 000. Custom designed 
software was and is still priced well over $100 000. PC-based LIMS systems 
have been developed and PCs in the laboratory can be networked to fully utilize 
this type of LIMS. 

Joseph Goulden of Laboratory Management Systems Inc., a New York consult- 
ing firm (ref. 1), advises that LIMS may not be suitable to all laboratories. 

He proposes that in a small laboratory, "the labor savings may not justify a 
system purchase. Maybe just a change in procedure, in logging in or routing, 
can clear up a problem." A database management program running on a PC may be 
all that is required for data handling. 

One of the major reasons a LIMS is not accepted in a laboratory is that 
the users are not consulted about their needs or those needs are ignored by the 
designers. When the idea is still in the design stage, users should be asked 
for their input. Henry Ledgard (ref. 2), a private consultant specializing in 
software engineering and education, states that if "human factors are impor- 
tant, they should be a concern from the beginning to the end of the software 


9 


life cycle... Human engineering is not something that can be grafted on to an 
existing system. It is the fiber of technical development." How menus are 
organized, if special function keys might be helpful, what notations are to be 
used for data entry, etc. are the types of questions good technical designers 
should consider. When users are given a chance to have input and make recom- 
mendations, they tend to feel more comfortable with the final product. 

This is one area where our LIMS design failed. The microstructural labo- 
ratory has a very efficient manual system for handling analysis requests and 
reporting sample results. The feasibility study failed to impress on our 
management the potential problems associated with trying to replace this system 
with a computerized one. The analysis reports generated by SEM, TEM, and X-ray 
Diffraction analysis are not numeric in nature but rather photographs and text 
which cannot readily be put into the required computer format. The feasibility 
study did not present enough advantages in this area to warrant the full LIMS 
capability for the microstructural lab. Prototyping, had it been done, would 
have revealed some of the weaknesses associated with the original LIMS design. 

A modified version which included scheduling for the user instruments, an 
instrument log for maintenance and supplies, a sample submission form and an 
analysis completion record could have provided enough data for management 
reports, sample status and instrument usage in the microstructural laboratory. 

Ira Cotton from Booz-Allen and Hamilton Consultants, has a selection 
criteria for choosing a local area network which can also be applied when 
selecting a LIMS. 


Functional i ty 
Performance 
Maintainabi 1 ity 
Extensibi lity 
Vendor stability 
Price 


capabilities provided 

speed of retrieval, error handling 

rel iabi 1 i ty 

growth potential 

experience, reputible 

within budget (ref. 3) 


Functionality and performance requirements should be determined by examin- 
ing what your lab does, how data-flow is handled, and what steps are required 
by both the submitter and the analyst. This structured analysis should be 
incorporated in the initial design. Once the design is completed, those 
responsible for managing the laboratory should decide whether this structured 
environment, which LIMS may impose, is desired in the laboratory. John Domanico 
(ref. 4), senior quality engineer for Warner-Lambert, recalls that "we did not 
identify all our needs in depth before going out and buying things; as a result 
we had to do more work to fix the software." Taking the time to do a thorough 
analysis prior to deciding on a LIMS may save time, money and much frustration 
1 ater . 


Maintainibility and extensibility are the next critical features of a 
LIMS. As we have learned, if a system is unreliable due to either hardware or 
software failures, new users will be uncomfortable with and therefore reluctant 
to use the system. A few considerations when implementing a LIMS according to 
Raymond Dessy, professor of chemistry at Virginia Polytechnic Institute, are: 


* 
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(1) No more than a day should be required to learn to use the system. 

(2) No more than a month should be required to become a skilled 
programmer. 

(3) The ability to implement change quickly and frequently is a necessity 
(ref. 5). 

Vendor stability and price should be considered in order to determine how 
much in-house support will be required. By utilizing the idea of prototyping, 
the vendor's understanding of the requirements will be evident. This can also 
reveal the need for modifications in the design. In our case, if a prototype 
had been developed which dealt with the specific needs of each laboratory, the 
project team could then have tested it for weaknesses and suggested possible 
changes to the design. Prototyping would have generated a baseline system 
with all the critical features. Once the baseline was operational, adding the 
options could have been the responsibility of the project team. Had this pos- 
sibility existed, the LIMS project might have had a better chance of being 
implemented in both laboratories. 

The electronics industry has been rapidly improving capabilities in disk 
storage, processor speed, compatibility, and networking. Many industry stan- 
dards have been developed within the past 5 years to make choices on types of 
hardware and software easier for the consumer. Our LIMS was designed during 
this period of rapid growth and as a result was obsolete by the time it became 
operational. Networking today is more readily accomplished through industry- 
accepted standards which utilize commercially available local area networks 
(for example, Ethernet or Decnet). It is evident that once standards have been 
established, individuals or industry as a whole can better utilize technology 
in developing applications and improving data management and communications. 
Laboratory information management systems will continue to be viewed as state- 
of-the-art for data management and communications in many laboratories for 
years to come. 
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APPENDIX A 


LEWIS INFORMATION NETWORK (LINK) 

The LINK, NASA Lewis' local area cable network, was designed by Mitre 
Corporation of Bedford, Massachussetts and is based on CATV technology. The 
system uses a pair of parallel broadband coaxial cables, one cable to carry 
the inbound signals and the other for the outbound signals. The frequency 
range extends from 50 to 300 MHz on each cable with the frequencies divided 
into 6 MHz band channels. Both data and video signals are transmitted via 
this cable sytem with the inbound and outbound signals being coupled at the 
head-end thus providing two-way communications. 


BUS INTERFACE UNITS (BIUs) 

These BIUs were made by Digital Communications Corporation of Bethesda, 
Maryland. The BIUs are Z80-based and were programmed in-house to perform the 
packetizing, routing and error-checking of LIMS network-bound data. The proto- 
col running on the LINK utilizes the resource sharing concept where each 
resource, whether it be a computer, terminal, or printer is known to the net- 
work and declares itself available or unavailable and must specify the number 
of users it can handle simultaneously. When users want to access a resource 
they either specify the channel or make a call to a front-end processor which 
routes the call to the appropriate channel. Once the channel is opened, it 
remains open until explicitly closed by either the receiving or transmitting 
end. The LIMS computer was configured to handle up to 16 network channels 
simultaneously. 


DCA-205/1 1 STATISTICAL MULTIPLEXER CIRCUIT BOARD 

The LIMS computer contains a DCA-205/11 statistical multiplexer circuit 
board made by Digital Communications Associates of Norcross, Georgia. The DCA 
board, which plugs into the Unibus backplane on the PDP 11/24, emulates a 
series of DEC DZ-11 serial multiplexer boards. Because these DZ-11 boards are 
supported by the PDP 11 /24s, the LIMS computer requires no special software to 
communicate with users via the DCA board. The DCA boards use DEC'S Digital 
Data Communication Message Protocol (DDCMP) to control data transmission with 
the BIUs. An in-house program was written for the BIUs to provide translation 
between the DCA-DDCMP protocols and the LINK protocol. This handler program 
allows the 16 user I/O ports on the LIMS computer to access the LINK and also 
identifies the port number and channel required for two-way communications over 
the LINK network. 
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Laboratory Information Management System 
Add a User to LIMS 


User Initials 
User Name 
Password 
Profes . Code 
Org . Code 
Phone 

Address 


Date : 

Class : 

Workstation Code: 
Mail Stop: 


Street /Number 

City State Zip 


Figure 1. User Dictionary Entry Form 
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Laboratory Information Management System 
Analyst Functions 

Analysis requests and assignments 
Enter analysis results and information 
Display workstation queue lists 
Report ing f unc t ions 
Time charging functions 
Miscellaneous functions 
Help 
Quit 


Figure 2. The analyst's menu 


Laboratory Information Management System 
Manager Functions 

Analyst Functions 
Management Reports 
Data Administration 
System Operations Function 
Miscellaneous Functions 
Read Mailbox 
Help 
Quit 


Figure 3. The manager's menu 


Laboratory Information Management System 
Customer Functions 

Analysis requests 
Sample status displays 
Print sample labels 
Print batch receipts 
Help 
Quit 


Figure 4. The customer/guest ' s menu 


Laboratory Information Management System -- Sample Mark-Up 
Task number: 

Engineer's initials : 

Submitter name: 

Organization code: 

Mail stop: 

Phone : 

Project link number: 

Return sample after analysis (Y/N)? 

Batch description (Optional - up to 5 lines that will appear 

on final report) 


Figure 5. 
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